Recently, communication technology adopting status grasping technique utilizing a concept called “presence” is vigorously developed. “Presence” means the current status of a user. It is enabled by notifying “presence” to another user at real time to grasp mutual current status. The communication technology adopting “presence” includes instant messaging (IM) as representative communication technology executed at the current stage. The concept of IM using presence information and its notification method are standardized with Instant Messaging and Presence Protocol (impp) working group of Internet Engineering Task Force (IETF) in the center. The contents standardized in the impp working group are described in a non-patent document 1 and a non-patent document 2.
Heretofore, the status grasping technique using “presence” is provided mostly in the form that the technique is added to IM service and a protocol acquired by extending a protocol for IM service originally configured by each company is used. However, recently, standardization at a level of a protocol is positively made. For example, in “Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions” (SIMPLE) working group of IETF, a presence information transmission/reception protocol acquired by extending a session initiation protocol (SIP) utilized in an IP phone and others is standardized. In a non-patent document 3 and other Internet drafts, its standard specifications are described. Recently, some companies try to integrate a protocol of IM service developed by each company with service using SIP such as the IP phone and a TV phone in accordance with SIMPLE standard. Besides, there is also movement to develop a presence server according to SIMPLE standard and to propose the usage of presence in a form in which presence is separated from IM service.
IM service basically premises service on one terminal of one user. For example, suppose that a user A utilizing IM service owns plural terminals, a terminal A and a terminal A′ and currently utilizes IM service on the terminal A. In case the user A simultaneously logs in an IM server on the terminals A and A′, the current IM server cannot judge to which of the terminals A and A′ the server should transmit an instant message to be transmitted to the user A from a user B who is another user. In the current IM service, when the user A tries to log in on the terminal A′ in case the user A logs in on the terminal A, a measure is taken by providing a mechanism for preventing double login such as forced logout on the terminal A on the side of the server.
In case SIP is used, a model that allows double login exists. However, the function is specific to the IP phone. The reason is that SIP is a standard that originally targets the IP phone. The model of double login by SIP will be described below.
FIG. 13 shows a state in which a user B denoted by 312 logs in an SIP server 41 on two IP phones denoted by 314, 315. At this time, the user B transmits REGISTER message of SIP to log in the SIP server 41 from the two terminals 314, 315. FIG. 5 shows the contents of the REGISTER message. Priority can be specified by specifying q-value denoted by 73 shown in FIG. 5 when the REGISTER message is transmitted on each terminal. Numerals 0 to 1 are specified in q-value and the terminal where a higher value is specified is regarded as the one having higher priority. For example, when 0.5 is specified in q-value on the IP phone terminal 1 denoted by 314 and 0.7 is shown in q-value on the IP phone terminal 2 denoted by 315, the SIP server 41 hereafter gives priority over the IP phone terminal 2 because the IP phone terminal 2 denoted by 315 has a higher value in q-value. When a user A calls the user B in this state, the SIP server 41 calls the IP phone terminal 2 having higher priority out of the terminals in which the user B logs. In the standard of SIP, the double login of the terminals is managed according to the above-mentioned method.    [Non-patent document 1] RFC 2778    [Non-patent document 2] RFC 2779    [Non-patent document 3] RFC 3265    [Non-patent document 4] IETF Internet Draft draft-ietf-impp-cpim-pidf-0.8.txt
In conventional type IM service, the IM server manages only a screen name (user ID) of a user who logs in and the corresponding online/offline status information and does not manage the type information of his/her terminal. In view of a situation in which SIP is installed of an IM system of each company, possibility that the system is configured based upon a common protocol such as SIP and the IM service and other service are managed with the configured system as a common platform is high. Therefore, afterward, it is estimated that various types of terminals such as an IM terminal, an IP phone and a chat terminal will be connected on the common platform. Further, it is estimated that not only a different terminal will be connected every application but the same terminal on which plural applications are executed will be connected to the common platform. Therefore, when a method of utilizing presence information which is performed in the conventional type IM service is applied as it is in case various service using presence information is developed on a network, it is considered that inconvenience shown in FIG. 11 will occur.
FIG. 11 is a schematic drawing showing a case that a user A who owns an IP phone terminal 211 calls a user B who owns plural terminals 213 to 216 via the SIP server. Suppose that the IP phone terminal 211 of the user A is connected to a presence server that manages the presence information of each terminal user and as a result, the IP phone terminal knows the presence information of the user B shown in a balloon 217. Also suppose that each terminal is connected to the SIP server as a session management server and the SIP server executes the communication control of each terminal. A full line shows a transmission path of a session signal communicated between the terminal and the SIP server and an alternate long and short dash line shows a transmission path of presence information.
The conventional type IM server manages a screen name of the user A and status information that the user A′ terminal 211 is turned online in pairs. In case a method of managing presence information in IM service is applied to the presence server as it is, the presence server manages user ID and the corresponding online/offline status information in pairs. Suppose that the user B simultaneously instructs a TV phone terminal 213, an IP phone terminal 214, a meeting terminal 215 and an IM terminal 216 to log in. As the presence server manages user ID, it can notify the user A of the online/offline status information of each terminal of the user B as shown in the balloon 217. Then, suppose that the user A would like to call the IP phone terminal B which is currently online of the user B. Needless to say, in case the user A knows all the address information of the user B, communication between the user A and the user B itself is possible. However, as the presence server does not manage the type of each terminal, the user A does not know which of the partner's terminals is the IP phone terminal even if the user A would like to communicate by the IP phone. Therefore, the destination terminal which the user B actually calls out of the terminals owned by the user B cannot be specified.
As described in the prior art, a model that one user doubly instructs plural terminals to log in exists in SIP, however, in this model, inconvenience occurs. For example, suppose that the terminal 315 is not an IP phone terminal but a terminal such as a TV phone terminal and a meeting terminal except an IP phone. As the SIP server 41 does not recognize it, the user A calls the terminal having the highest priority out of the terminals which the user B instructs to log in and except the IP phone even if the user A calls the user B by the IP phone in this state. As a result, the type of the terminal to which the user A transmits and the type of the terminal where the user B receives are different and no call comes into effect.
As described above, in case only an IP phone exists on an SIP network, the double log-in model comes into effect, however, in case various terminals except an IP phone exist, inconvenience occurs in the model using the q-value.
When a terminal type is diversified by making a protocol common, an amount of information may be short by only the following presence information when each terminal utilizes the presence information having the same name. For example, a balloon 227 shown in FIG. 11 shows a state in which each terminal utilizes presence information of a name “closed” in common. Suppose that each terminal 213 to 216 registers the current session status of each terminal at an either value of “closed” or “open” in a part in which the name of the presence information is called “session status”. The user A can acquire the current session status of each terminal owned by the user B from “session status”. However, no concrete calling means is described in “session status”. Therefore, even if the following result is shown as denoted by 227 as a result of acquiring presence information, it is unknown by what means a call is actually made. Therefore, the user A can grasp a partner's state only at a level that the user A who is an originator cannot communicate with the user B currently because the user B on the receive side is simply communicating with someone. If the user B actually communicates by character chat, the user A interrupts it, however, the user A can ring a telephone in an emergency and at this time, the user on the side of an originator loses one timing of communication.